Cloudwatch Metrics x Alarmを理解しよう！！
CloudwatchのMetricsは意外と理解するの大変。慣れてないと何してるのか訳わからんのでポイントを順番に抑えることが大事。
参考情報は全部舐めまわして理解した方がいい。
最初は何言ってるかわからないだろうけど、それでも頑張って何回も往復すれば理解できると思う
1. まずは「メトリクス・データポイント」を理解する
hr.icon
Cloudwatchというサービス自体の役割は「AWSリソースとAWSで実行するアプリケーションを監視する」というもの。
監視するための一番重要な仕組みが「メトリクス 」
Cloudwatchには「EventBridge」「Logs」などのサブサービスもあるが、それを差し置いても一番重要。
（そもそも「EventBridge」や「Logs」は、「Cloudwatch本体」とは兄弟ではあるが、ほぼ別サービス扱い）
メトリクス（metrics）とは何か
監視対象のタイムスタンプにおけるデータ/数値（データポイントと言う）を一定期間の区切り（解像度）で集めたセット。
それぞれのメトリクス からは、集めたデータポイントを利用した統計値を取得することができる。
最大値、最小値、平均値、サンプル数など
ややこしい & 勘違いしやすいポイント
1.icon測定対象から取ったデータ全体を指してメトリクスとは言わない
区切り（解像度）を決めた後にできるデータポイントを纏めた各セット1つ１つをメトリクスと言う。
対象を分析する際は、データポイントだけだと細か過ぎてわからないので、メトリクスを利用することになる。
主体はデータポイント（いわゆる生データ）。メトリクスは対象を評価するための集計。
データポイント1つ1つがタイムスタンプと対象の値（ex：CPU使用率32.4%）を持ってる
https://scrapbox.io/files/61c35be778f998001e3c14cb.png
CPU使用率を分析するのを言葉で表現すると、以下のようになる。
➡️例１「CPU使用率における日時A 〜 日時Bまでの1分メトリクスを取得する」
➡️️例２「CPU使用率における日時C 〜 日時Dまでの3分メトリクスを取得する」
基本的には取ったメトリクスの統計値を時系列に並べてグラフにしたりする。
Cloudwatchのダッシュボードで見れるやつ。
上記の図の1分区切りメトリクスを参考にすると...
「1分メトリクスのサンプル数を利用してグラフ作成」
-> 時系列が早い順から「2, 2, 1, 3, 2, 0」がグラフになる。
2.icon実は...データポイントはそのまま保存されてはおらず、1分（or 1秒）のメトリクスに即座に集約されてる
1.iconでは「主体がデータポイント」と言ったが、実際のところデータをそのまま保存してる訳ではない。
そんなことをしたら、データ保存量が増えすぎて、コストが大変なことになる。
記録（パブリッシュ）されたデータポイントは、即座に1分メトリクスに集約されて保存。（1秒は後で後述）
3.iconメトリクスは「区切り」によって保存期間が決まってる
https://scrapbox.io/files/61c3600618dc32001d6782f5.png
データポイントとあるが...今までの流れを汲むと、メトリクスと捉え直したほうがわかりやすい。
重要なことは...以下。
区切りの短いメトリクスが消失したとしても、それより長い区切りのメトリクスは利用できる。
解像度は多少荒くなるが、長い区切りのメトリクスでカバーできてる期間のデータは、一応そのメトリクスの統計値に反映されてる。
4.icon基本的にメトリクスの最小単位は1分なのだが...最低1秒からの高解像度メトリクス というのもある
高解像度メトリクスは「区切り」を1秒にまで短くできる。
高解像度を利用すると料金がとても高くなるので、必要になるまでは標準解像度メトリクス （利用可能区切りが最短1分）を利用した方がいい。
高解像度メトリクスは「カスタムメトリクス 」でしか設定できない。
メトリクス 作成時に、標準 or 高解像度を選択できる。
2. データポイントを発行する者たち
hr.icon
AWSが用意したメトリクスは、各担当サービスが勝手にデータポイントを発行してる。
逆にカスタムメトリクス の場合は、各ユーザーが発行を実装しなくてはいけない。
AWSメトリクスへのデータポイント発行者
各AWSサービスが発効する。こやつらは様々な時間間隔でデータポイントを発行してくる。
例えば、EC2だと5分で発行してくる（詳細モニタリングで1分に変更することも可能）。
もっと言うと、彼らはデータポイントを発行する前に、発行間隔「区切り」のメトリクスを作って発行する。
どういうこと？
つまり、「どうせ集約するなら、先に集約しておいてあげる」ってことで、各サービスが集約してから発行してる。
カスタムメトリクスへのデータポイント発行者
発行方法は発行の仕組みの作成者次第。
AWSサービスのようにメトリクスにしてから発行してもいいし、逆にデータポイントをそのまま発行するでもいい。
ただ、発行の回数にお金がかかるので、どうせ最低1分のメトリクスになるなら、AWSサービスのように集約してから発行した方がお得。
高解像度メトリクスの場合は話が別だが...
3. メトリクスとアラームの関係
hr.icon
Cloudwatch Alarmは何者か。簡単に言うと、メトリクスを監視して指定ルールの閾値を超えたら発火するやつ。
このサービスはメトリクスを監視して、一定期間の中でメトリクス の値が閾値を超えたら、1つ以上のアクションを実行する。アクションと言っても、基本的にはSNSに情報を流す形になる。
1つのアラームが1つのメトリクスを監視するのが基本
公式では複合アラームとかいう謎の設定もあるが、基本的には1アラーム - 1メトリクスが原則。
アラームには3つのステータスがある
OK：メトリクスや式は、定義されているしきい値の範囲内
ALARM：メトリクスまたは式が、定義されているしきい値を超えてる
INSUFFICIENT_DATA：アラームが開始直後であるか、メトリクスが利用できない、メトリクスが足りない。
アラームの評価方法で大事なのは「監視間隔（=期間）」「評価期間」「アラームに必要なデータポイント数」
監視間隔（=期間）
公式でもマネコンの設定でも「期間」と名付けられてるが、自分は監視間隔と捉えた方が理解しやすかった。
これはアラームがメトリクスの値を取得しにいく間隔のこと。
例えば1分と指定したら、アラームは1分毎に指定メトリクスの値を取りに行き、その度に評価する。
評価期間（Evaluation Periods）
評価に必要なメトリクス値（データポイント）の数のこと。
評価期間が10なら、アラームを発火するかの評価のためにメトリクス値が10個必要ということになる。
監視間隔が1分で、評価期間が10なら、10分前から現時点までのメトリクス値を利用することになる。
アラーム実行に必要なデータポイント数（Datapoints to Alarm）
評価期間の中でアラーム発火に必要なデータポイント数。
例えば、評価期間が10でこの値が5なら、10のうち5以上のデータポイントが閾値を超えてなければアラームが発火しないことになる。
「評価期間」と「アラーム実行必要数」を以下のような形で表すことが多い
アラーム実行必要数 / 評価期間
よくある例
1 / 1：1回ごとにアラーム評価。
1 / 3：過去3回の中で1回の値がデータポイント超えてたらアラーム発火
欠落データの扱い
欠落データ
例えばアラームが1分毎にメトリクス値を見に行ったとしても、メトリクス値が取得できない場合があったりする。
これを欠落データと言う。
欠落する理由は様々である。データポイントを送るエージェントが壊れててデータが記録されてなかったり、メトリクス値がそもそも5分毎にしか取得されないようになっており1分毎のデータが取得できなかったり。
アラームの設定では「欠落データ」をどう扱うかの話もある。
1. 閾値を超えたものと同等の扱いをするか
2. 無視するか
基本的には「1」で扱うことが多い。
4. まとめ
hr.icon
以上のことを頭に入れつつ、公式ページを深く読んだり様々なブログを読んでみると、より理解が深まる。
以下の参考情報は目を通しておくといいと思われる。特にBlackBelt。
参考情報（上から順にちゃんと読んだほうがいい）
公式ドキュメント
BlackBelt
その他、理解度上がりそうな記事